mkShellMinimal: Create an ultra minimal nix-shell #132617

fzakaria · 2021-08-04T04:35:54Z

Motivation for this change

This shell is inspired some investigation I did
and a follow-up example that demonstrated starting a nix-shell with a minimal builder.sh.

The goal is to provide the facility to create an ultra-lightweight nix-shell that only has bash as the direct dependency. Users can set environment variables and add packages but the feature-set is purposely minimal.

The following Nix expression works and is pointing to the latest commit of this PR

let
  nixpkgs = import (builtins.fetchTarball {
    name = "nixpkgs-fzakaria-fork-2021-08-03";
    url =
      "https://github.com/fzakaria/nixpkgs/archive/refs/heads/faridzakaria/pure-mkShell.tar.gz";
    sha256 = "1h7aqlivq2hax7k7a612mffpfkawn1mfd3jfszzpx19i2fxwmqp2";
  }) { };
in
with nixpkgs;
mkShellMinimal {
  name = "my-test-shell";
  packages = [ ripgrep ];
  FOO = bar;
}

This minimal nix-shell has effectively a 0 (1.4 KiB) size closure.

❯ nix path-info -rSsh $(nix-build -I nixpkgs=/home/fmzakari/code/github.com/NixOS/nixpkgs test-shell-local.nix)
these derivations will be built:
  /nix/store/xaqxyk1y3zjk0qwpxkm0n3n6c05bj6fn-setup.drv
  /nix/store/rxrbwvk7rjvknil7ns1ki00n4vfqcs8h-my-test-shell.drv
building '/nix/store/xaqxyk1y3zjk0qwpxkm0n3n6c05bj6fn-setup.drv'...
building '/nix/store/rxrbwvk7rjvknil7ns1ki00n4vfqcs8h-my-test-shell.drv'...

This derivation is not meant to be built, unless you want to capture the dependency closure.

/nix/store/8ka1hnlf06z3h2rpd00b4d9w5yxh0n39-setup        	 376.0 	 376.0 
/nix/store/nprykggfqhdkn4r5lxxknjvlqc4qm1yl-builder.sh   	 280.0 	 280.0 
/nix/store/xd8d72ccrxhaz3sxlmiqjnn1z0zwfhm8-my-test-shell	 744.0 	   1.4K

Things TODO

I am still missing the necessary hook to clear $PATH when nix-shell is started pure. This exercise has actually shown how tied the nix-shell and stdenv concepts are.
Add support for inputDerivation similar to what @infinisil added for mkDerivation
calculate the new closure-size (should be 0?) for the minimal shell.

Things done

pkgs/top-level/all-packages.nix

pkgs/build-support/mkshell/minimal.nix

Mic92 · 2021-08-04T04:44:44Z

There is a section for special builders in nixpkgs doc nixpkgs/doc/builders/special/mkshell.section.md
This one could be added as well.

tomberek

What is the goal? If to be minimal is there a path to use busybox instead of bash?

pkgs/build-support/mkshell/minimal.nix

fzakaria · 2021-08-04T04:56:13Z

What is the goal? If to be minimal is there a path to use busybox instead of bash?

In practice I found we were using nix-shell to have a reproducible environment, but stdenv was bringing and doing a lot of stuff. I just wanted the ability to declare environment variables & a list of packages.
(Might need to expand slightly to setup-hooks for setting stuff like language paths like bundler or Java's classpath)

I want to showcase an ultra-minimal mkShell (in fact the real mkShell should probably be built on-top of this), where one lists only a set of packages.

The whole notion of buildInputs vs. propagatedBuildInputs is unnecessary is you are writing a shell. You are never planning to build the derivation.

fzakaria · 2021-08-04T05:18:40Z

There is a section for special builders in nixpkgs doc nixpkgs/doc/builders/special/mkshell.section.md
This one could be added as well.

I will work on documentation once I get a few more 👀 on this. I have a few TODOS I added to the description that I still need to solve (if you have hints please share).

siraben · 2021-08-04T06:51:34Z

@fzakaria thanks for working on this!

@tomberek a more minimal shell would be good for packages that don't need the full closure of stdenv, which has occurred for me while working on #123095. Maybe one based on busybox instead of bash would be even more minimal indeed. See #116274 for an stdenv based on uutils-coreutils.

pkgs/build-support/mkshell/minimal.nix

roberth · 2021-08-04T12:39:15Z

pkgs/build-support/mkshell/minimal.nix

+
+      for a in $packages; do
+        export PATH=$a/bin:$PATH
+      done


You'll also want to set XDG_DATA_DIRS, because that's what bash uses to find completion scripts on demand. Stdenv sets it generically since #103501, which inspired devShell to do the same.

It comes at a very very little cost, but does enable shell completions.

If that's not the design choice you want to make, I wonder if it should even set PATH. Maybe someone only wants to set another environment variable, in which case PATH is redundant.

I guess it boils down to the question "when is it not a shell anymore?" which is obviously not clearly delineated, but needs an answer for this to be actually minimal.

Also, in what regard is it minimal? I would define it as the combination of the number of store paths and the total byte size. The latter is generally so disproportionally determined by dependencies that the size of the shellHook (or similar) does not matter, as long as it doesn't increase store path count.
I do consider store path count separately because it introduces latency with nix-copy-closure and most binary caches.

I would say minimal with regards to closure size but from that we could support features to make the whole thing practical usable i.e. set MANPATH.

pkgs/build-support/mkshell/minimal.nix

fzakaria · 2021-08-04T16:42:08Z

pkgs/build-support/mkshell/minimal.nix

+  builder = writeScript "builder.sh" ''
+    #!${bash}/bin/bash
+    echo
+    echo "This derivation is not meant to be built, aborting";
+    echo
+    exit 1


@infinisil I actually don't see a particular reason why nix-shells can't be buildable.
I wonder if doing your export trick here to $out is enough + adding an error message.

fzakaria · 2021-08-04T16:45:45Z

@siraben since there's no dependency on coreutils (merely bash); I like that this in spirit allows the user to choose busybos or coreutils.

I think keeping the sole dependency to bash more in spirit to this minimalism otherwise the choice will no longer be possible?
There might be an opportunity to remove bash completely and solely rely on /bin/sh which must exist on the system ?

roberth · 2021-08-04T16:58:51Z

~~nix-shell will start the bash on the derivation's PATH,~~ so you'd need some trickery to start a different shell. Such trickery isn't minimal and it's unexpected, so I'd leave it up to the user if they really feel like they need it.

Please don't use /bin/sh. It's only intended for programs that make calls to the C system function and such.

fzakaria · 2021-08-04T17:00:27Z

@roberth makes sense.
Looks like the size of bash vs. busybox is the same mostly due to the size of glibc's locales.
There's an opportunity to use a version of bash with an overridden glibc that only has UTF8 as the supported LOCALE.
(should dramatically reduce the minimal size)

roberth · 2021-08-04T17:05:31Z

The user should choose their own bash implementation if they don't want to use the impure PATH's bash, so optimizing it is another topic.

Did you mean to use /bin/sh in the builder? That's not so bad, because that's not used for the actual shell and the builder logic is, well, super simple.

fzakaria · 2021-08-04T17:06:45Z

@roberth i did mean it for the builder since the expectation is that it's run on a POSIX compliant machine and for the purpose of having a development environment.

fzakaria · 2021-08-04T17:11:04Z

Woot!
New closure size is merely 1.4KiB

❯ nix path-info -rSsh $(nix-build -I nixpkgs=/home/fmzakari/code/github.com/NixOS/nixpkgs test-shell-local.nix)
these derivations will be built:
  /nix/store/xaqxyk1y3zjk0qwpxkm0n3n6c05bj6fn-setup.drv
  /nix/store/rxrbwvk7rjvknil7ns1ki00n4vfqcs8h-my-test-shell.drv
building '/nix/store/xaqxyk1y3zjk0qwpxkm0n3n6c05bj6fn-setup.drv'...
building '/nix/store/rxrbwvk7rjvknil7ns1ki00n4vfqcs8h-my-test-shell.drv'...

This derivation is not meant to be built, unless you want to capture the dependency closure.

/nix/store/8ka1hnlf06z3h2rpd00b4d9w5yxh0n39-setup        	 376.0 	 376.0 
/nix/store/nprykggfqhdkn4r5lxxknjvlqc4qm1yl-builder.sh   	 280.0 	 280.0 
/nix/store/xd8d72ccrxhaz3sxlmiqjnn1z0zwfhm8-my-test-shell	 744.0 	   1.4K

andir · 2021-08-04T17:41:01Z

Do you also plan to support inputsFrom (and potential other features that I am unaware of) from mkShell?

fzakaria · 2021-09-29T03:07:30Z

I'd love to collaborate to continue to make this composable.
I envision a way where you "stack" features onto the minimalShell setup for various features you want.
(Stdenv.mkDerivation would be just a prebuilt stack)

Didn't get a chance to chat more with @zimbatm more about it.

erikarvstedt · 2021-09-29T09:11:59Z

I'd like to see this included in nixpkgs. mkShell is not fit to use as a general purpose env builder due to the number of irrelevant env vars. @zimbatm, would you join this effort?

pkgs/build-support/mkshell/minimal.nix

Co-authored-by: Sandro <sandro.jaeckel@gmail.com>

asymmetric · 2022-03-07T10:09:33Z

@fzakaria are you still planning on working on this? I would be interested in seeing it land in nixpkgs.

roberth · 2022-03-07T10:30:23Z

I'm increasingly convinced that development shells should be started through nix run, giving complete control to expressions that can be pinned, rather than relying on fragile, complicated built-in behavior that is inherently hard to improve upon.

It's a technically and organizationally superior solution, but the hacky nix-shell solution has a dedicated subcommand and a decade of usage :'(

asymmetric · 2022-03-07T21:37:28Z

@roberth do I understand correctly that your
concern is about how this is run, rather than how it’s implemented? If so, it should be orthogonal to this PR?

roberth · 2022-03-07T22:16:26Z

@roberth do I understand correctly that your concern is about how this is run, rather than how it’s implemented? If so, it should be orthogonal to this PR?

My concern is that this PR uses the wrong tool to achieve its goal, as nix-shell is too complicated to host a minimal shell. Note that nix-shell is a hack of all trades but master of none, as evidenced by the many nix issues that want to pull it either in the direction of nix run or the actual real build sandbox.
It is certainly not orthogonal, but I won't oppose incremental changes like this PR, as long as you're making the conscious choice to go for a messy local optimum rather than a principled solution.

colemickens · 2022-03-07T22:21:56Z

I'm not sure how to make sense of these thoughts given that I use mkMinimalShell with nix develop (I don't really know the internal differences between nix-shell/nix run/nix develop. How does that compare to nix run?

tomberek · 2022-03-07T23:59:16Z

I'm not sure how to make sense of these thoughts given that I use mkMinimalShell with nix develop (I don't really know the internal differences between nix-shell/nix run/nix develop. How does that compare to nix run?

Roughly:

nix run: just run the installable using an absolute path.
nix shell: set the PATH to the "bin" of the installable (and from /nix-support/propagated-user-env-packages) and start a sub-shell with "$SHELL" or "bash" using normal /etc/profile or bashrc or zshrc initialization.
nix develop: set a ton of variables that would be present during a build. start a sub-shell using a bootstrap rcfile that calls the setupHook for the derivation you are using.
nix-shell: various things

nix run can simulate the others as it can run some arbitrary script

fzakaria · 2022-03-08T01:23:46Z

The discussion and PR i would like to continue to push forward is breaking down mkShell in composable units.
I was trying to setup the barest (smallest) unit first to start and everything else should compose on top of it.

@roberth I don’t think anything in mkMinimalShell goes against what you are saying. It’s creating a shell to inherit all environment variables. I agree I would like to see less specified in nix Itself for defining this stuff.

Thoughts?

roberth · 2022-03-08T09:26:46Z

@roberth I don’t think anything in mkMinimalShell goes against what you are saying.

My only concern is that it may not achieve its end goal, but that doesn't mean that it doesn't have value. As I said, I won't oppose incremental changes like this PR.

barest (smallest) unit first to start and everything else should compose on top of it.

This is a good goal, but you'll be duplicating significant parts of "stdenv". We already have a NixOS way of configuring the environment and a stdenv/setup/mkDerivation way of configuring environments. Will this create a third way of doing things?

Perhaps a better angle for implementing this is to modularize stdenv. We have stdenvNoCC which, as the name suggests, does not include the C compiler. Similarly, you could define more minimal "env"s. I'd stay away from negations like "NoCC" and construct ones that are minimal with respect to some goal. Maybe you could have setupenv which relies on an impure environment, but runs setup.sh; shenv which builds on that but makes the shell pure; unixenv which adds a small number of programs used in scripts; busyboxenv, etc.
This feels like bootstrapping, but I don't know if these distinctions/layers are useful for that. As far as I'm concerned, these envs' dependencies should all be built with the usual stdenv, to keep things simple.

By using those minimal envs, you can modularize shells using the same functionality that is used for builds, such as the setup hooks, and you don't have to introduce a third way of doing things.

asymmetric

Documentation suggestions.

asymmetric · 2022-03-08T11:34:36Z

doc/builders/special/mkshellMinimal.section.md

+with nixpkgs;
+mkShellMinimal {


Can we remove this super-broad use of with from the doc? It doesn't seem to add anything over

Suggested change

with nixpkgs;

mkShellMinimal {

pkgs.mkShellMinimal {

asymmetric · 2022-03-08T11:35:06Z

doc/builders/special/mkshellMinimal.section.md

+
+```nix
+let
+  nixpkgs = import <nixpkgs> { };


Suggested change

nixpkgs = import <nixpkgs> { };

pkgs = import <nixpkgs> { };

Since you use pkgs.mkShellMinimal above (and is more idiomatic IMO)

fzakaria · 2022-03-08T14:55:22Z

I see a long term goal of rebuilding stdenv or stdenvNoCC using a new modular format. Right now it's subtractive rather than additive which makes it difficult to think through.

…

On Tue, Mar 8, 2022, 1:26 AM Robert Hensing ***@***.***> wrote: @roberth <https://github.com/roberth> I don’t think anything in mkMinimalShell goes against what you are saying. My only concern is that it may not achieve its end goal, but that doesn't mean that it doesn't have value. As I said, I won't oppose incremental changes like this PR. barest (smallest) unit first to start and everything else should compose on top of it. This is a good goal, but you'll be duplicating significant parts of "stdenv". We already have a NixOS way of configuring the environment and a stdenv/setup/mkDerivation way of configuring environments. Will this create a third way of doing things? Perhaps a better angle for implementing this is to modularize stdenv. We have stdenvNoCC which, as the name suggests, does not include the C compiler. Similarly, you could define more minimal "env"s. I'd stay away from negations like "NoCC" and construct ones that are minimal with respect to some goal. Maybe you could have setupenv which relies on an impure environment, but runs setup.sh; shenv which builds on that but makes the shell pure; unixenv which adds a small number of programs used in scripts; busyboxenv, etc. This feels like bootstrapping, but I don't know if these distinctions/layers are useful for that. As far as I'm concerned, these envs' dependencies should all be built with the usual stdenv, to keep things simple. By using those minimal envs, you can modularize shells using the same functionality that is used for builds, such as the setup hooks, and you don't have to introduce a third way of doing things. — Reply to this email directly, view it on GitHub <#132617 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAETXDTCPV7SR57ISBXSKH3U64MOFANCNFSM5BQG55SA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

johnrichardrinehart · 2023-09-26T05:17:19Z

@asymmetric Are you still requesting changes? I'd like @fzakaria to be able to merge this, if possible.

asymmetric · 2023-09-26T15:43:43Z

@johnrichardrinehart I don't think my review is the main thing blocking this (but @fzakaria please do let me know if that's the case). There are conflicts that must be resolved.

But on the topic of my review: I especially think we shouldn't advocate the "global" with in the manual. There were some issues explaining its problems but I can't find them now.

roberth · 2023-09-28T11:49:39Z

A truly minimal shell would not have the form of a derivation, however this requires changes in the Nix CLI.

Reverts commit d16d129. This did not work since many depend on stdenv. References: - NixOS/nixpkgs#132617 - NixOS/nixpkgs#116274

nixos-discourse · 2024-07-07T20:04:08Z

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/make-shell-a-modular-replacement-for-mkshell/48509/12

fzakaria force-pushed the faridzakaria/pure-mkShell branch 2 times, most recently from e251480 to 42ce8dd Compare August 4, 2021 04:37

Mic92 requested a review from zimbatm August 4, 2021 04:38

Mic92 reviewed Aug 4, 2021

View reviewed changes

pkgs/top-level/all-packages.nix Show resolved Hide resolved

fzakaria force-pushed the faridzakaria/pure-mkShell branch 2 times, most recently from 8c9ce8e to 9001dc0 Compare August 4, 2021 04:43

fzakaria commented Aug 4, 2021

View reviewed changes

pkgs/build-support/mkshell/minimal.nix Outdated Show resolved Hide resolved

tomberek reviewed Aug 4, 2021

View reviewed changes

pkgs/build-support/mkshell/minimal.nix Outdated Show resolved Hide resolved

pkgs/build-support/mkshell/minimal.nix Outdated Show resolved Hide resolved

fzakaria force-pushed the faridzakaria/pure-mkShell branch from 4900f19 to 7bc58d0 Compare August 4, 2021 04:52

ofborg bot added 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 0 This PR does not cause any packages to rebuild on Linux labels Aug 4, 2021

fzakaria force-pushed the faridzakaria/pure-mkShell branch 2 times, most recently from 591435f to b6ac56e Compare August 4, 2021 05:06

fzakaria requested review from infinisil and basvandijk August 4, 2021 05:08

fzakaria changed the title ~~minimalMkShell: Create an ultra minimal nix-shell~~ mkShellMinimal: Create an ultra minimal nix-shell Aug 4, 2021

roberth requested changes Aug 4, 2021

View reviewed changes

fzakaria commented Aug 4, 2021

View reviewed changes

fzakaria force-pushed the faridzakaria/pure-mkShell branch from 6da01e0 to 2931a05 Compare August 4, 2021 17:13

SuperSandro2000 reviewed Oct 27, 2021

View reviewed changes

pkgs/build-support/mkshell/minimal.nix Outdated Show resolved Hide resolved

legendofmiracles mentioned this pull request Nov 25, 2021

mkShell alternative that doesn't include stdenv, for use with direnv or impure nix develop #147060

Open

veprbl added the 2.status: merge conflict This PR has merge conflicts with the target branch label Nov 25, 2021

Update pkgs/build-support/mkshell/minimal.nix

d6a34c2

Co-authored-by: Sandro <sandro.jaeckel@gmail.com>

asymmetric requested changes Mar 8, 2022

View reviewed changes

roberth mentioned this pull request Jul 18, 2022

Legacy stdenv.mkDerivation #295044

Open

stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Sep 21, 2022

roberth mentioned this pull request Dec 23, 2022

Allow to get rid of nix develop "shell" logic NixOS/nix#7501

Open

infinisil added the significant Novel ideas, large API changes, notable refactorings, issues with RFC potential, etc. label Apr 19, 2023

stale bot removed the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Apr 19, 2023

wegank added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Mar 19, 2024

wegank marked this pull request as draft March 20, 2024 15:27

m15a added a commit to m15a/bump.fnl that referenced this pull request Mar 25, 2024

ci: revert "ci: remove deps to gcc"

c54fad6

Reverts commit d16d129. This did not work since many depend on stdenv. References: - NixOS/nixpkgs#132617 - NixOS/nixpkgs#116274

stale bot removed the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jul 7, 2024

roberth mentioned this pull request Jul 29, 2024

[WIP] devShellTools.buildShellEnv #330822

Draft

19 tasks

mkShellMinimal: Create an ultra minimal nix-shell #132617

Are you sure you want to change the base?

mkShellMinimal: Create an ultra minimal nix-shell #132617

Conversation

fzakaria commented Aug 4, 2021 • edited Loading

Motivation for this change

Things TODO

Things done

Mic92 commented Aug 4, 2021

tomberek left a comment

Choose a reason for hiding this comment

fzakaria commented Aug 4, 2021

fzakaria commented Aug 4, 2021

siraben commented Aug 4, 2021

roberth Aug 4, 2021

Choose a reason for hiding this comment

roberth Sep 18, 2021

Choose a reason for hiding this comment

roberth Sep 18, 2021

Choose a reason for hiding this comment

Mic92 Sep 18, 2021 • edited Loading

Choose a reason for hiding this comment

fzakaria Aug 4, 2021

Choose a reason for hiding this comment

fzakaria commented Aug 4, 2021

roberth commented Aug 4, 2021 • edited Loading

fzakaria commented Aug 4, 2021

roberth commented Aug 4, 2021

fzakaria commented Aug 4, 2021

fzakaria commented Aug 4, 2021

andir commented Aug 4, 2021

fzakaria commented Sep 29, 2021

erikarvstedt commented Sep 29, 2021

asymmetric commented Mar 7, 2022

roberth commented Mar 7, 2022

asymmetric commented Mar 7, 2022

roberth commented Mar 7, 2022

colemickens commented Mar 7, 2022

tomberek commented Mar 7, 2022

fzakaria commented Mar 8, 2022

roberth commented Mar 8, 2022

asymmetric left a comment

Choose a reason for hiding this comment

asymmetric Mar 8, 2022

Choose a reason for hiding this comment

asymmetric Mar 8, 2022

Choose a reason for hiding this comment

fzakaria commented Mar 8, 2022 via email

johnrichardrinehart commented Sep 26, 2023

asymmetric commented Sep 26, 2023

roberth commented Sep 28, 2023

nixos-discourse commented Jul 7, 2024

fzakaria commented Aug 4, 2021 •

edited

Loading

Mic92 Sep 18, 2021 •

edited

Loading

roberth commented Aug 4, 2021 •

edited

Loading